Debugging typically involves the use of a debugger, a tool that allows a software developer to observe run-time behavior of a computer-program and locate semantic errors. Some debugging commands such as a stop command allow the programmer to halt execution of a running process at any time. Whereas manual insertion of breakpoints allow the programmer to halt the process when predetermined points in the code have been reached. The debuggee runs free until it hits a break op-code in the instruction stream, at which point the operating system (OS) will halt the debuggee until the debugger continues the debuggee. Thus, when debugging a computer-program, the program is either running (i.e., executing as a process) or halted. Certain debugging commands, such as step-into, step over, and step-out commands, function only in break mode (i.e., when the debugee is halted), and allow the programmer to step through the program state, observe and/or modify content of variables, pointers, and/or the like.
Traditional stepping is done via placing break op-codes at strategic points via static analysis of the instruction stream, and then running free until a respective patch is encountered (hit). For instance, step-in places a patch at the start of the function being stepped into, step-over places a patch after a line being stepped over, and step-out places a patch at an instruction that will execute once a current function returns. Unfortunately, such conventional stepping commands do not allow programmers to automatically skip “uninteresting code”. Rather, as described above, programmers are required to manually insert breakpoints in interesting code and execute until a breakpoint is hit, and/or manually step-through uninteresting code to get to the interesting code. In other words, programmers may be required to iteratively (line-by-line) step-into and through uninteresting code, step-over a function and possibly land in uninteresting code, and/or step-out of a function and possibly land in uninteresting code.
For instance, step-into and step-over commands differ only in the way they handle function calls. Either command instructs the debugger to execute the next line of source code. If the line contains a function call, the step-into command executes only the call itself, and then halts at the first line of code inside the function, regardless of whether that first line of code is uninteresting code. The step-over command executes the entire function, and then halts at the first line outside the function, regardless of whether that first line is uninteresting code. On a nested function call, step-into steps into the most deeply nested function. For instance, if step-into is used on a call like F1(F2( )), the debugger steps into the function F2. The step-out command is used to step-out of a function by resuming program execution until the function returns, and then breaks execution at the return point in the calling function, regardless of whether the return point corresponds to uninteresting code.
Additionally, although a debugger can be instructed to iteratively execute the step-in command for each respective line of code to single step-through a portion of code, this process substantially reduces debugging process performance and substantially increase risk of process deadlock (i.e., contention for a same cache-line because the debugger). For instance, to emulate multiple iterative step-in operations, the debugger, for each line of code: inserts a breakpoint at the next instruction, runs the process, catches the associated exception, and then examines the instruction pointer to determine if a preconfigured stopping point has been reached (or until the debugger has been manually stopped). As can be appreciated such iterative operations, wherein the debugger does not execute more than a single line of code before another exception is thrown (i.e. the code is only allowed to “run-free” for a very short amount of time) can considerably hinder debugging performance and increase the possibility of process deadlocks. For purposes of discussion, code that runs-free is a logical block of code such as a method or uninteresting code that is allowed to execute unhindered by encountered breakpoints.
Such debugging limitations become especially problematic when the computer-program being debugged is designed to operate in a sophisticated environment that integrates large amounts of code that the programmer is not interested in debugging. Such uninteresting code may include, for example, code that the programmer did not write, already debugged code, other shared code, networked service code, interoperability framework code, and/or the like. In such a scenario, existing techniques to debug a program that do not allow the programmer to easily skip uninteresting code may require time consuming and labor intensive efforts that could become overwhelming to both novice and experienced programmers alike.
Accordingly systems and methods to allowing a user to debug only code of interest, without having to manually set breakpoints in interesting code, and/or manually step-through uninteresting code to reach interesting code are greatly desired.